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Large amounts of data about every customer line number and 
billing number in the country must be available for the Stored 
Program Controlled (spc) Network features to operate. A method of 
obtaining, organizing, and cleansing the data or administering the 
necessary network data bases was needed. While much of the data 
could be obtained through each telephone company's service order 
system, these systems vary substantially in capabilities from one 
company to another and even from one region to another of the same 
company. To obtain the data, a new support system called the No. 2 
Data Base Administration System (dbas) was designed and new 
operational procedures for the telephone companies were developed. 
The dbas interacts with all types of service order systems to obtain 
the data; provides initial load, as well as immediate and routine 
updates for the network data bases; and handles customer queries, 
statistics, special studies and other administrative functions off-line 
for the data bases. This minicomputer- based system bridges the gap 
between the telephone company paper flow and the spc network. The 
dbas provides reliable data in a timely fashion to the network to 
ensure the viability of the initial features. It provides a general 
capability for administration of additional customer data which may 
be required for future spc network features. 

I. INTRODUCTION 

As discussed in companion articles of this issue of The Bell System 
Technical Journal, large amounts of data on every customer billing 
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number (a line number or special billing number) in the country must 
be available to various nodes in the spc network for the network 
features to function properly. (See Ref. 1 for a discussion of the on-line 
data bases.) A method of obtaining, organizing, and cleansing the data, 
that is, administering the network data bases or Billing Validation 
Applications (bvas), is needed. While the data can be obtained through 
each telephone company's (Bell or independent operating company) 
Service Order System (sos), these systems vary significantly in capa- 
bilities and design from one telephone company to another and even 
from one region to another of the same company. Further, no existing 
telephone company administration system had all of the sos data 
currently used or envisioned for spc network features. 

To obtain the data and provide the administrative functions, a new 
support system called the No. 2 Data Base Administration System 
(dbas) was designed. [The No. 1 dbas administered data bases in 
Automatic Intercept System (ais) switching machines.] The opera- 
tions of the Data Base Administration Center (dbac), the telephone 
company center which operates the dbas, were revised to reflect its 
new capabilities. 

By defining a specific interface, dbas interacts with all types of soss 
to obtain the necessary data. The dbas will accept data link, magnetic 
tape, and manual clerk input, thus functioning in all of the modes of 
telephone company data entry for sos information. 

The dbas is connected by one dedicated data link to each bva 
containing billing number records administered by that dbas. It is 
expected that, in most cases, there will be only one or two bvas 
attached to a single dbas, although the dbas is designed to handle up 
to four bvas. Backup links are also provided for use when dedicated 
link failures occur. A backup terminal, connected to each bva by a 
dedicated link, is located at the dbac for use in accessing the bva. 

The dbas provides the means for initially loading, as well as updat- 
ing, the bva. It is also capable of auditing the bva for inconsistencies 
and of restoring some or all of the bva, if a catastrophic failure (both 
active disks and both backup disks are lost) occurs at the bva. From 
the telephone company's viewpoint, the dbas is the primary repository 
for the information that comprises the bva, and for the information 
that is needed to administer the various features. That is, the dbas 
contains a superset of the bva information. (The bva contains only 
those items needed by the requesting nodes for the on-line processing 
and billing of calls.) This superset of bva information is stored in a 
data base at the dbas. The dbas also handles customer inquiries, 
statistics, and other administrative functions associated with the spc 
network features. Thus, these functions are performed off-line from 
the switching network. 
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This minicomputer-based system bridges the gap between the tele- 
phone company paper flow and the spc network. The dbas provides 
reliable data in a timely fashion to the network to ensure the viability 
of the initial features. It provides a general capability for administra- 
tion of additional customer data which may be required for future spc 
network features. 

II. SERVICE ORDER DATA 

All customer Billing Number Record (bnr) activity originates in 
either a Public Service Marketing Center, Residence Service Center, 
or Business Service Center. The AT&T recommendation is for the 
record of this activity to be transmitted by service order. Standard 
Universal Service Order Codes (usocs) and Field Identifiers (fids) 
have been developed to accommodate all data required to support 
Calling Card Service features. However, some companies may also 
transmit selected data by miscellaneous form or memo. All data are 
obtained from completed service orders with the exception of public, 
semipublic, and coinless Originating Station Treatment (ost) data, 
which are obtained from precompleted service orders. 

Both the dbas and bva data bases are designed so that the data 
forwarded by the sos are stored by utilizing the 10-digit telephone 
number (npa-nxx-xxxx) or special billing number (rao* 0/1 xx-xxxx) 
as the address. Furthermore, the data themselves are logically grouped 
into four categories corresponding to the features offered by Calling 
Card Service. These categories are as follows: 

(i) Originating station treatment — The service order contains 
usoc information for each line, indicating whether that line has Touch- 
Tone* or rotary dial capability. It may also contain, at the customer's 
request, fid information if special ost is desired. These data are used 
to determine the protocol returned to the calling station (Tone, Tone 
and Announcement, or Operator Assistance) on 0+ calls. 

These data are translated by the sos and transmitted in the appro- 
priate format to the dbas. 

(ii) Public telephone check (ptc) — The service order also contains 
a usoc which identifies the class of service for each line, i.e., residence, 
business, public, semipublic, or coinless. These data are used to deter- 
mine if special operator handling is required on collect or bill-to-third- 
number calls. 

(Hi) Billed number screening (bns)— The service order contains an 
fid providing toll billing exception for those customers that request 

(a) no collect or bill-to-third-number calls 



* Revenue Accounting Office. 

+ Registered service mark of AT&T. 
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(b) no bill-to-third-number calls 

(c) no collect calls. 

(iv) Calling Card Validation — Finally, the service order contains a 
usoc which indicates the assignment of Calling Card service. This 
information is transmitted from the sos to the Customer Record 
Information System (cris). The cms, upon receipt of these data, uses 
an algorithm to generate a four-digit personal identification number 
(pin) which is associated with the billing number. On a daily basis, the 
cris system forwards the billing number + pin information to the 

DBAS. 

A block diagram indicating the source and flow of data is shown in 
Fig. 1. 

In summary, bnr information is recorded on service orders. This 
information is then transmitted by locally developed soss directly to 
dbas and cris. The cris generates Calling Card Service information 
and transmits these data to the dbas. 

III. SYSTEM ARCHITECTURE 

The detailed system architecture of DBAS is the subject of a com- 
panion paper appearing in this issue. However, a high-level description 
of the architecture will be provided here as an aid to the reader in 
understanding the remainder of this paper. 

Figure 2 is a simplified block diagram showing the functional rela- 
tionship of the No. 2 dbas programs associated with processing updates 
to the dbas and bva data bases.* 

As noted previously, updates are entered into the dbas from paper 
records, magnetic tape, or via high-speed data link. The dbas programs 
associated with these three types of data entry are clerkin, readtape, 
and linkin, respectively. These programs check the data input for 
syntax, completeness, and self-consistency, and they output a logical 
grouping of 1 to 256 updates called a session file. Each completed 
session file is linked both to the Journal Program (jurnl) and order 
processors. The journal program copies the sessions to magnetic tape 
so that they may easily be reinput if a system malfunction should 
occur before they are completely processed. 

Operating independently from jurnl, the order processor programs 
also begin their work. For a given update, the associated bnr infor- 
mation is retrieved from the data base and, using this additional 
information, further consistency checks are performed on the input 
record. If the record passes the checks, the dbas data base is modified 
and an update for the bva is generated. When an entire session is 



* Programs associated with processing ais and tsps updates are not shown. 
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processed, the associated group of updates (also called a session) is 
passed to the bva transmission program (bvatrans). 

If a session passed to bvatrans is designated high priority, 
bvatrans will immediately transmit the associated updates to the 
BVA. All other sessions will wait until a designated time, usually during 
the middle of the night (the lowest traffic period for the bva), to be 
processed. At that time, bvatrans will sort the updates in order of 
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input data. Errors found are printed on the dbac line printer for 
subsequent investigation. 

The magnetic tapes read are industry standard, nine-track, and 
employ recording methods and densities which meet the American 
National Standards Institute (ansi) specifications. Both 1600-cpi, 
Phase Encoded (pe) and 800-cpi, non-return-to-zero, change-on-ones 
(nrzi) tapes can be utilized. 

Input tapes must adhere to the following format. First, there is an 
80-character block termed the "Volume Header Label," which identi- 
fies the physical reel of magnetic tape. This is followed by another 
block of 80 characters called the "File Header Label," which identifies 
the contents of the "file," that is, the data recorded on the tape. 

The file is a collection of input records containing bns, Calling Card 
Service, ptc, ost, and ais data. The input records are grouped into 
sessions, where the input records in a session have all come from the 
same source (e.g., the same telephone company). Multiple sessions on 
a tape must be used to separate input records from different telephone 
company or different regional soss within a telephone company. The 
maximum number of input records per session is generally limited to 
256. Each session is started by a session header which indicates the 
source of the data (the telephone company). An "End-Of-File Label" 
follows the file. This is an 80-character block which identifies the end 
of all input data records recorded on the tape. Also recorded on the 
tape are single-character blocks containing a Device Control (dc3) 
character. These are termed "tape marks." One tape mark precedes 
the file, one succeeds the file, and two follow the End-of-File Label. 

VI. SERVICE ORDER DATA-LINK INPUT— LINKIN 

The dbas data-link input program, linkin, provides the capability 
to receive service order information on a real-time basis from a single 
telephone company sos. This method of operation has advantages 
over magnetic tape input in that it allows immediate updates to be 
input without the manual intervention of dbas clerks. Data-link input 
is otherwise functionally equivalent to tape input. That is, the format 
of sessions input to, and output from, the linkin program are essen- 
tially identical to those associated with the readtape program. In 
addition, the consistency and syntax checks performed by the two 
programs are also identical. 

The communication protocol used for the data-link input is BX.25, 
which has been adopted as the Bell System standard for communica- 
tion between Operations Support Systems, and between these systems 
and spc switching systems. The physical data link consists of two four- 
wire private lines. Data are normally transmitted over only one of the 
lines, with the alternate line serving as a "hot" standby. In case of 
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excessive transmission errors, the data flow is automatically switched 
from the active line to the standby without loss or duplication of 
information. Communication over the link is full-duplex synchronous 
at a speed of 4800 baud. 

VII. JOURNAL TAPE— JURNL 

The jurnl program functions to produce a journal tape which is 
the image of the on-line data base additions and modifications from 
the clerkin and linkin processes since the beginning of the work 
day. The readtape input may also be journaled to consolidate mag- 
netic tapes. In the case of a system failure, if the integrity of the on- 
line data base is in doubt, the system may be restored, using the 
journal tapes to efficiently reinput the day's updates. 

Tapes produced by the jurnl process are compatible with the 
requirements of readtape. To assure compatibility, journal tapes are 
created in the same format described previously for the readtape 
process, pe and 800 or 1600 cpi. 

The production of a journal tape involves the interchange of mes- 
sages with the console operator. Messages to and from jurnl pass 
through a control program (control) and follow the formats specified 
therein. These messages are invaluable aids to procedures, such as 
tape mounting and dismounting, tape mount verification, system shut- 
down, and system restart. The messages also highlight operator or 
tape errors. For example, it is in the best interest of dbas to have a 
journal tape mounted whenever input sessions are being processed. 
The following error message is printed regularly whenever input ses- 
sions are in the journal directory but when no tape is being written. 

++ (jurnl) SESSIONS ARE WAITING TO BE JOURNALED, 
PLEASE MOUNT JOURNAL TAPE 

The jurnl program is started by control when DBAS is started and 
runs continuously until the operator requests either a total system 
shutdown or a selective process shutdown. The jurnl program, how- 
ever, will only write to tape after operator action. After a shutdown, 
jurnl ceases to exist. It will be automatically started the next time 
dbas is started, or the operator may restart it manually. 

VIM. ORDER PROCESSING 

As was described above, in general, the order processing programs 
accept sessions from the input programs, update the dbas data base 
and/or generate updates for the bva transmission program. Also, since 
the order processing programs have access to the data base records, 
they can perform certain additional consistency checks which the 
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Table II — Order processor functions 



Performs 

Reads Consist- Writes Generates 

Order Accepts Input Data Base ency Data Base bva Up- 

Processor From (bnrs) Checks (bnrs) dates 

ilop Magnetic tape No Yes Yes Yes 

uop Clerk, data Yes Yes Yes Yes 

link, magnetic 

tape 

pop Not applicable Yes No Yes Yes 

mop Not applicable Yes No No Yes 



input programs could not. Any inconsistencies are reported to the 
dbac via exception reports written to the line printer. 

In actuality, there are four different order processor programs. These 
are the Update Order Processor (uop), the Initial Load Order Proc- 
essor (ilop), the Pending Order Processor (pop), and the Move Order 
Processor (mop). Each of these is discussed briefly below. Table II 
summarizes the functions performed by each order processor. 

8. 1 Update order processor 

There are four uop programs which process daily updates from the 
clerkin, readtape, and linkin programs. Multiple uops are used to 
implement the requirements for handling various updates at different 
levels of priority. 

One uop processes only immediate, or high-priority updates. Im- 
mediate updates can be generated by clerkin or linkin (but not by 
readtape) to handle denials, restorals, or customer trouble reports. 
Since one uop is dedicated to handling immediate updates and because 
the number of immediate updates required is relatively small, an 
immediate update is processed and ready for transmission to the bva 
within 10 minutes. Naturally, if the immediate updates were handled 
by the same uop as lower priority updates, processing time would be 
extended as a result of the intermingling of updates. Otherwise, a more 
complex program would be required to allocate resources appropri- 
ately. 

For similar reasons, another uop is dedicated to handling non-high- 
priority clerk updates. Thus, since the number of these clerk updates 
is generally small compared to the mechanized input, clerk updates 
get processed relatively quickly (within 1 hour) also. 

Finally, the third and fourth uops are dedicated one each to read- 
tape and non-high-priority linkin inputs. Since the quantity of mech- 
anized updates is relatively large, and handled on a first-come, first- 
served basis, these updates are given resultantly lower priority han- 
dling by default. 
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8.2 Initial load order processor 

The ilop is the order processor used to perform an initial load or 
reload of the dbas data base. 

Since several million records may have to be loaded initially, input 
for the ilop must be provided in a special restricted format to speed 
processing. The ilop accepts only input from readtape. Furthermore, 
the initial load tape must be organized in sessions each of which consist 
of all the bnrs for a given Billing Number Group (bng). After perform- 
ing syntactical checks, the ilop places the records in the session in an 
order required for the data base to store the entire session efficiently 
rather than store each record individually. In addition, the ilop 
provides the session to bvatrans for subsequent transmission to the 

BVA. 

8.3 Pending order processor 

A pending order is an update for Calling Card Service data which 
was input via one of the input programs with an effective date some- 
time in the future. That is, it is a Calling Card Service update which 
must take effect 24 hours or more later than the time on which it was 
entered. For instance, if a customer telephone number change is to 
take place seven days in the future, a pending order must be generated 
to delete the pin from the old number on that effective date. The pop 
is the program which searches the dbas data base for pending orders 
having a given effective date, updates the data base with the pending 
data, and generates the appropriate update to pass on to bvatrans 
for transmission to the bva. The pop is normally run manually once a 
day after regular updating is complete. 

8.4 Move order processor 

The mop is actually not an order processor, but simply a program 
which can read bnrs from the dbas data base and supply the records 
to bvatrans for transmission to the bva. Thus, it provides a means to 
restore the bva data base directly from the dbas data base should 
such a need arise. 

IX. DATA BASE ADMINISTRATION SYSTEM— INTERNAL DATA BASE 

The dbas internal data base contains the data needed by the bva 
and associated data for off-line activities, such as customer inquiries. 
There is a bnr for each billing number assigned to the dbas. The data 
kept for each bnr is shown below, with the default values (that is, the 
meaning of the absence of data in a given field) in italics. 

(i) ost indicator: Customer- requested, tone, tone and announce- 
ment, cut through to an operator, or none 
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(ii) Service indicator: Touch-Tone service, rotary dial service, or 
unknown 

(Hi) ptc data: Public coin, public-coinless, semipublic-coin, busi- 
ness, or residence, or unknown; 

(iv) bns code: Customer requested no bill-to-third number, no 
collect, no bill-to-third number or collect, or no restrictions 
(v) Unrestricted PIN (no pin) 

(ui) Service denial bit for unrestricted pin (no service denial) 
(uii) Service start for unrestricted pin date (no date) 
(viii) Restricted pin (no pin) 
(ix) Service denial bit for restricted pin (no service denial) 
(x) Service start date for restricted pin (no date) 
(xi) Date of most recent dbas data base update activity and 
medium (clerk, tape, or data link) of the update for this record (no 
date, no medium) and priority of last update 

(xii) Counter to indicate the number of pending orders for this bnr 

(zero). 

When an update results in default values for all data items in a 
billing number record (except for item xi), the dbas deletes this billing 
number record from its data base. 

The data kept for a billing number group (i.e., bng— the 10,000 
numbers with common npa-nxx or rao 0/lxx) include: 

(i) Status: Vacant, nonparticipating, no input allowed, local ad- 
ministration or active administration for bva administration* 

(ii) Date that each feature (Calling Card Services, bns, and ost) 
was activated in the bva. No date indicates that the feature is not 
enabled. 

(Hi) Current rao + (no rao): This rao corresponds to the rao 
stored in the bva for the billing purpose. 

(iv) Previous rao (no rao): This rao should be the same as the 
current rao code for the bng. It corresponds to the rao stored in the 
bva for the rao digit (raod) check. 

(v) Ownership: Telephone company that owns this bng (no id ) 
(vi) bva(s) identity: Where this bng resides (no bvas) 
(vii) Activity counts: Number of inserts, deletes, or changes since 
last daily report (zero for all) 



* Vacant means that the bng is vacant and no bnr input is allowed; nonparticipating 
means that the bng is active, but no billing number records are associated with the bng; 
local administration means that no bnr updates are being sent to the bva(s); no input 
allowed means that the bng is being moved or restored; active administration means 
that the bnr updates are being forwarded to a bva. 

'When changing the rao code for the bng, the new rao should be entered as the 
current rao and forwarded to the bva. After the transition period of rao change is over, 
the dbac personnel should manually reset the previous rao to be the same as the 
current one. 
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(viii) Date that the billing number records in this bng were initially 
loaded in the dbas data base. No date indicates that the data are not 
loaded. 

The dbas data base interfaces functionally in two ways with the rest 
of the system. It provides administrative data for reports and studies, 
and it supports order processing, which consists of insertion, deletion, 
and changes to records in the data base. 

9. 1 Administration of data base 

There are two dbas administration programs, getbng and getbnr, 
which permit the dbac administrator to access the data base infor- 
mation described above. First, before any bnr information can be 
entered into the data base, the getbng program must be used to 
initialize, for administration, the appropriate bng records. This pro- 
gram has the capability of inserting, updating, deleting, or listing any 
information in the bng record. Second, a listing of the bnr data (which 
was entered through the clerkin, linkin, or readtape programs) is 
provided by the getbnr program. Thus, the dbac administrator can 
easily determine the contents of any bnr record in the data base. 

X. BILLING VALIDATION APPLICATION TRANSMITTER— BVATRANS 

The bva transmission program (bvatrans) is responsible for con- 
trolling the flow of all updates from the dbas to the bva(s). To do this, 
bvatrans operates on files of bva updates produced by the seven 
order processor programs discussed above. These operations include 
sorting, formatting, and transmitting immediate and batch updates. 

The sorting operation is required to group all updates for bnrs 
within a given bng. Transmission of updates grouped in this way saves 
a considerable amount of bva real time. In addition, the sorting 
operation helps bvatrans to prevent the possible overwriting of an 
immediate update by an earlier batch update which is transmitted at 
a later time. 

XI. SYSTEM ADMINISTRATION 

In addition to the programs associated directly with the data base 
updating functions, which were described above, the dbas provides a 
set of system administration programs. These programs fall into two 
broad categories: (i) system parameter generation and (ii) report gen- 
erating. The system parameter generation programs allow the system 
administrator to describe the hardware configuration of the particular 
dbas and generate various system tables and files which are unique to 
that site's operations. The report-generating programs provide statis- 
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tics describing various aspects of the daily operations and the status of 
system processes and files. 

The specific functions of these administrative programs are de- 
scribed in more detail below. 

11.1 System parameter generation 

There are four major administrative programs which are used to 
define data unique to a particular dbas. These programs are sysgen, 

CLOSTRANT, ACCESSRST, and ORDERTYPE. 

11.2 SYSGEN 

sysgen is the administrative program used to define various param- 
eters associated with the ais, tsps, and bva interfaces and to define 
clerk login ids. In addition, it is also used to define optional peripheral 
equipment including tape drives, disk drives, terminals, and data links. 
Because of this, the sysgen program must be run before updating and 
other system activities can begin. 

Generally, the first time the sysgen program is run, the initialization 
function is performed to establish values for all of the required system 
parameters. When performing the initialization function, the sysgen 
program prompts the user with a question and the user responds with 
the appropriate value for that particular parameter. When all of the 
parameters have been initialized, the user "quits" the program, thus 
causing the parameter file just created to be stored on the system disk 
for subsequent use by all other programs. 

After the first parameter initialization is completed, other functions 
which may be performed by sysgen include: 

(i) Update — change the current value of a specified parameter 
(ii) Print — print all or any data parameter 

(Hi) Backup — save all parameters on magnetic tape 

(iv) Restore— transfer all parameters from magnetic tape to disk. 

It was noted above that sysgen is an interactive program, that is, 
the program prompts the user for appropriate responses. However, as 
is the case for most all of the DBAS programs, sysgen can also operate 
in a command mode, whereby an experienced user can input on one 
line data normally input on several lines in response to several sysgen 
prompts. 

11.3 CLOSTRANT 

The system administrator uses the clostrant program to build a 
Class of Service Translation Table. This table is then used by the dbas 
data input programs (clerkin, readtape, and linkin) to translate 
the class of service code on the service order to one of the six internal 
class of service codes used by the dbas and bva. A translation of this 
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type is required since a telephone company may need several hundred 
different class types to define all of the different categories of telephone 
service which are tariffed (and so appear on the service order), whereas, 
from the dbas and bva viewpoint, program efficiencies are gained by 
having to work internally only with the six classes which completely 
define the service for the line from the standpoint of the Calling Card 
Service, bns, ost, and ptc features. 

The actual clostrant table built by the administrator consists of 
up to 750 entries, each of which gives the internal dbas class of service 
code which was assigned to the particular usoc. The clostrant 
program provides commands to edit and print the table, while magnetic 
tape backup and restore for the table are provided by the correspond- 
ing sysgen features. 

11.4 ACCESSRST 

The accessrst program is used by the administrator to define 
which clerks and which telephone company will be allowed access to 
given sets of bngs for updating purposes. For example, to provide 
access restrictions for data input via clerk terminal, a table is built for 
each clerk id specifying which bngs can be accessed under that id. 
Likewise, to provide access restrictions for data input via magnetic 
tape or data link, a table is built for each telephone company id 
specifying which bngs can be accessed by that telephone company. 
These access restrictions help ensure that billing number record data 
are not modified from an unauthorized source. 

The accessrst program provides commands to initialize a new 
table, modify, delete, and print existing tables, or create a new table 
which is identical to an existing table. Tables are named C100 to C999 
and T000 to T255 for the corresponding clerk and telephone company 
ids, respectively. 

11.5 ORDERTYPE 

As was described above, the clerk input program is an interactive 
data entry system based upon a sequence of up to 32 questions which 
the clerk answers from information on the service order or a trouble 
report. To maximize the efficiency of the entry process, the sequence 
of questions asked is based upon the order-type code entered by the 
clerk. This order-type code is the second question asked and is pre- 
ceded only by the entry of the billing number. 

Using the ordertype program, the dbas administrator creates and 
maintains a file which defines the question sets for up to 64 order-type 
codes. In addition to specifying the question sets, the administrator 
defines which questions the clerk may skip and which questions will 
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automatically receive specified fixed answers. Thus, the clerk input 
program may be tailored to the needs of the particular dbac. 

Specific capabilities provided by the ordertype program include 
the ability to print the order-type file, insert new order types, modify 
existing order types, and delete order types. 

11.6 Report-generating programs 

There are several programs which have been provided to allow the 
administrator to monitor the performance and status of the dbac. All 
of these programs must be run manually by the administrator. Three 
of the programs provide daily operational statistics. These programs 
and their functions are as follows: 



ACTSTAT 



CLERKSTAT 



LINKSTAT 



Provides counts of the number of inserts, modifi- 
cations, and deletes of bnrs on a per-BNG or per- 
telephone company basis during a given day. 
Provides clerk performance statistics such as av- 
erage work time per update, clerk sessions can- 
celled, total time logged in, etc. One to eight sum- 
mary reports may be generated. 
Provides statistics regarding the health of all 
BX.25 data links. 



Other report-generating programs are run on an as-needed basis to 
investigate possible system trouble conditions and to assist the system 
administrator or operator with system shutdowns and restarts and file 
management. These programs and their functions are as follows: 

audprint Provides a summary of dbas/bva audit reports on 

a bng basis. 
bvaprint Provides a printout of the daily bva transmission 

file on a bng or BNR basis. 
systat Provides a report of all processes active in the 

DBAS at the time systat is run. 
files Provides a list of files accessible to various DBAS 

processes. The owner and size of the file, and date 

and time of last modification are given for each 

file. 



XII. DATA BASE ADMINISTRATION CENTER 

The dbac is responsible for the administration of the intercept 
number data used by ais and the Calling Card Service data stored in 
the dbas and bvas. The dbas is in the Operator Services organization 
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and is typically managed by one second-level manager and one to 
three first-level supervisors. 

The dbac uses the dbas as the principal means of administering the 
contents of bvas. The dbac also uses the direct terminal to the bva as 
backup for dbas outages and for certain administrative functions of an 
infrequent nature. 

The dbac activities can be separated into the following categories: 
(i) Administration, (ii) Updates, and (Hi) Support. 

12.1 Administration 

The administrative responsibilities of the dbac include the creation 
and maintenance of a data base environment in the dbas and bva 
which will allow for the storage of bnrs and their subsequent access 
and use by the ccis network for call-processing purposes. The activities 
required to do this are as follows: 

(i) Programming of the dbas nongeneric parameters via sysgen. 

(ii) Creation of the necessary tables, records, and files in the dbas 
to allow updating. These are bng records (created and maintained for 
each npa-nxx and rao-0/1xx assigned to the dbas location), Class of 
Service Translation Table, Access Restriction Tables, and Ordertype 
File. 

(Hi) Coordination and negotiation with AT&T Long Lines to ensure 
ccis and bva availability. The dbac must also coordinate the estab- 
lishment of new bngs and the migration of bngs between bvas or 
dbass. 

(iv) Administration of rao validation and the check-digit algorithm. 
The dbac inputs the check-digit algorithm as provided by AT&T and 
sets the transition indicators as required for rao and algorithm 
changes. 

(v) Schedule audits and perform necessary actions to resolve in- 
consistencies. The dbac runs audits between the dbas data base and 
the bva. Regular audits are under program control, but the dbac also 
initiates demand audits as required. The dbac is responsible for 
resolution of audit inconsistencies to ensure accurate dbas and bva 
data. 

(vi) Perform dbas file backups at prescribed intervals and, if re- 
quired, restore the dbas and bva files. Backup of the dbas system 
disk is done each working day and backup of the dbas data base is 
done once a week. Restoration of the dbas and the bva is done 
utilizing the backup disks and journal tapes retained for that purpose. 

12.2 Updates 

The dbac is responsible for the entering of updates into the dbas. 
Updates may be entered by data link, magnetic tape, or clerk work 

DATA BASE ADMINISTRATION SYSTEM 1 775 



station. The dbac must initiate the appropriate dbas programs to 
allow input from the above-mentioned sources. The dbac must resolve 
any incomplete or erroneous update information received by the dbas. 

The dbac must also run the pending order processor daily to update 
Calling Card Service information in a timely manner. 

If the dbas or the data link between the dbas and bva is not 
operational, the dbac must update the bva with the dbac/bva ter- 
minal to ensure accurate call processing. 

12.3 Support 

The dbac is responsible for the analysis, resolution, and clearance 
of data base trouble reports. Trouble reports are typically received 
from Centralized Repair Service, Answering Bureaus, Repair Service 
Bureaus, Business Service Center, and Residence Service Centers. In 
addition to these centers, clearance of trouble reports may also involve 
interaction with comptrollers, public services, AT&T Long Lines, and 
tsps Operator Services Facilities Administration. 

The dbac monitors the operational status of the dbac equipment 
including the dbas, data sets, and terminal equipment. This includes 
analyzing hardware/software problems and ensuring that corrective 
action is taken. The dbac is also responsible for ensuring the proper 
storage, cleaning, and transportation for magnetic tapes and disk units. 

The dbac must ensure that bng data maintained at the bva are 
accurate by reviewing all enabled services by bng and reviewing all 
query addresses assigned to the bva(s). In addition, the dbac coordi- 
nates with the AT&T Long Lines Engineering and Network Adminis- 
tration Center to ensure proper ccis network and bva operation, 
including matters concerning translations, migration, and data links. 

The dbac also initiates all special studies performed at the dbas or 
bva and reviews the bva counters and reports and takes corrective 
action, if required. 

XIII. SUMMARY 

The dbas was designed to bridge the gap between the business office 
and a new user of business office data, the spc network. The dbas 
interfaces with the various telephone company soss, which range from 
totally automated to totally manual, to obtain the information needed 
by the network to provide its services. The dbas keeps a superset of 
the data needed by the bvas in an internal data base so that many 
administrative functions, such as customer inquiries and special stud- 
ies, can be processed by the dbas; this relieves on-line network nodes 
from having to store extra data and process extra transactions which 
are not call related. After cleansing and ordering the service order data 
it receives, the dbas provides initial load and daily update capability 
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to the bvas it administers by way of data-link transmission. In case of 
a massive failure at a bva, the administering dbas can reload the bva's 
data. 

XIV. ACKNOWLEDGMENTS 

The work described in this paper required the participation of many 
dedicated people in various organizations at Bell Laboratories, Western 
Electric, AT&T, and the telephone companies. The authors wish to 
acknowledge the contributions of all the team members whose efforts 
are summarized here. 

REFERENCES 

1. R. G. Basinger, M. Berger, E. M. Prell, V. L. Ransom, and J. R. Williams, "Stored 
Program Controlled Network: Calling Card Service — Overall Description and 
Operational Characteristics," B.S.T.J., this issue. 



DATA BASE ADMINISTRATION SYSTEM 1 777 



